<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link href="../css/main.css" media="all" rel="stylesheet" type="text/css" />
<link href="../css/highlight.css" media="all" rel="stylesheet" type="text/css" />
<link href="../css/print.css" media="print" rel="stylesheet" type="text/css" />
<title>第5章 - symfonyを設定する</title>
</head>

<body>
<div class="navigation">

<table width="100%">
<tr>
<td width="40%" align="left"><a href="04-The-Basics-of-Page-Creation.html">前の章</a></td>
<td width="20%" align="center"><a href="index.html">ホーム</a></td>
<td width="40%" align="right"><a href="06-Inside-the-Controller-Layer.html">次の章</a></td>
</tr>
</table>
<hr/>
</div>

<div>
<a name="chapter.5.configuring.symfony" id="chapter.5.configuring.symfony"></a><h1>第5章 - symfonyを設定する</h1>

<p>シンプルで使いやすくするために、symfonyは少数の規約を定義します。これらの規約は修正を行わずに標準のアプリケーションの共通要件を満たします。しかしながら、シンプルで強力な設定の一式を利用することで、symfonyとアプリケーションを連携させる方法をほとんどカスタマイズできます。これらのファイルによって、固有のパラメーターをアプリケーションに追加することもできます。</p>

<p>この章では設定システムがどのように機能するのかを説明します:</p>

<ul>
<li>symfonyの設定はYAMLで書かれたファイルに保存されますが、つねに別のファイルフォーマットを選ぶこともできます。</li>
<li>設定ファイル(configuration file)はプロジェクトレベル、アプリケーションレベル、モジュールレベルでそれぞれプロジェクトのディレクトリ構造のなかに存在します。</li>
<li>複数のコンフィギュレーション設定の一式(セット)を定義できます。設定の一式は環境(environment)と呼ばれます。</li>
<li>設定ファイルで定義された値はアプリケーションのPHPコードから利用できます。</li>
<li>加えて、symfonyはYAMLファイルのなかでPHPコードを使うことや設定システムをはるかに柔軟なものにするしくみを公認しています。</li>
</ul>

<div class="toc">
<dl>
<dt><a href="#the.configuration.system">5.1. 設定システム</a></dt>
<dd><dl>
<dt><a href="#yaml.syntax.and.symfony.conventions">5.1.1. YAMLの構文とsymfonyの規約</a></dt>
<dt><a href="#help.a.yaml.file.killed.my.app">5.1.2. 助けてください、YAMLファイルを修正したらアプリケーションが動かなくなりました！</a></dt>
</dl></dd>
<dt><a href="#overview.of.the.configuration.files">5.2. 設定ファイルの概要</a></dt>
<dd><dl>
<dt><a href="#project.configuration">5.2.1. プロジェクトのコンフィギュレーション</a></dt>
<dt><a href="#application.configuration">5.2.2. アプリケーションのコンフィギュレーション</a></dt>
<dd><dl>
<dt><a href="#front.controller.configuration">5.2.2.1. フロントコントローラーのコンフィギュレーション</a></dt>
</dl></dd>
<dt><a href="#main.application.configuration">5.2.3. メインアプリケーションのコンフィギュレーション</a></dt>
<dd><dl>
<dt><a href="#internationalization.configuration">5.2.3.1. 国際化のコンフィギュレーション</a></dt>
<dt><a href="#additional.application.configuration">5.2.3.2. アプリケーションの追加コンフィギュレーション</a></dt>
</dl></dd>
<dt><a href="#module.configuration">5.2.4. モジュールのコンフィギュレーション</a></dt>
</dl></dd>
<dt><a href="#environments">5.3. 環境</a></dt>
<dd><dl>
<dt><a href="#what.is.an.environment">5.3.1. 環境とは何か？</a></dt>
<dt><a href="#configuration.cascade">5.3.2. 設定カスケード</a></dt>
</dl></dd>
<dt><a href="#the.configuration.cache">5.4. コンフィギュレーションキャッシュ</a></dt>
<dt><a href="#accessing.the.configuration.from.code">5.5. コードから設定にアクセスする</a></dt>
<dd><dl>
<dt><a href="#the.sfconfig.class">5.5.1. sfConfigクラス</a></dt>
<dt><a href="#custom.application.settings.and.app.yml">5.5.2. アプリケーションのカスタム設定とapp.yml</a></dt>
</dl></dd>
<dt><a href="#tips.for.getting.more.from.configuration.files">5.6. 設定ファイルからより多くの情報を得るためのティップス</a></dt>
<dd><dl>
<dt><a href="#using.constants.in.yaml.configuration.files">5.6.1. 定数をYAML設定ファイルのなかで利用する</a></dt>
<dt><a href="#using.scriptable.configuration">5.6.2. スクリプトを設定に組み込む</a></dt>
<dt><a href="#browsing.your.own.yaml.file">5.6.3. 独自のYAMLファイルを読み込む</a></dt>
</dl></dd>
<dt><a href="#summary">5.7. まとめ</a></dt>
</dl>
</div>
<a name="the.configuration.system" id="the.configuration.system"></a><h2>設定システム</h2>

<p>目的にかかわらず、多くのWebアプリケーションは共通の機能の一式を共有しています。たとえば、セクションは一部のユーザーに制限される、もしくはページはレイアウトによってデコレート(装飾)される、もしくはバリデーションが失敗したあとでフォームがユーザーの入力で満たされるなどです。symfonyはこれらの機能をエミュレートする構造を定義するので、開発者はコンフィギュレーション設定を変更することでこれらの構造をさらに調整できます。多くの変更は1行のコードを必要としないので、たくさんのコードが背後に存在するとしても、この戦略によって多くの開発時間が節約されます。これらの情報は単独で容易に識別できる位置で維持されるので、はるかに効率的でもあります。</p>

<p>しかしながら、このアプローチには重大な欠点が2つあります:</p>

<ul>
<li>開発者は複雑なXMLファイルを絶え間なく書かなければならない事態に陥ります。</li>
<li>PHPアーキテクチャにおいて、すべてのリクエストを処理する時間がはるかに長くなります。</li>
</ul>

<p>これらの不都合な点を考慮にいれると、symfonyでは設定ファイルが得意なことに対してのみ設定ファイルを使うことにします。実際のところ、symfonyの設定システムに望む多くのことはつぎのとおりです:</p>

<ul>
<li>パワフルである: 設定ファイルで管理できるほとんどすべての状況は設定ファイルを利用して管理する。</li>
<li>シンプルである: 変更をほとんど行わずにすむので、通常のアプリケーションにおいて多くの設定を行う状況に遭遇しない。</li>
<li>簡単である: 開発者が読みやすく、作成と修正を簡単に行うことができる設定ファイルである。</li>
<li>カスタマイズ可能である: デフォルトの言語はYAMLであるが、INI、XML、開発者が望む任意のフォーマットも利用できる。</li>
<li>速い: 設定ファイルはアプリケーションではなく設定システムによって処理される。設定システムは設定ファイルをPHPサーバーで速く処理されるコードの塊(チャンク)にコンパイルする(まとめる)。</li>
</ul>

<a name="yaml.syntax.and.symfony.conventions" id="yaml.syntax.and.symfony.conventions"></a><h3>YAMLの構文とsymfonyの規約</h3>

<p>symfonyは設定に対して、より伝統的なINIもしくはXMLフォーマットの代わりに、デフォルトでYAMLフォーマットを利用します。YAMLはインデント(字下げ)を通して構造を示すので速く書けます。その利点と基本ルールはすでに1章で説明しました。しかしながら、YAMLファイルを書いているときにいくつかの規約を覚えておく必要があります。このセクションではもっとも有名な規約をいくつか紹介します。このトピックを完全に卒業するには、YAMLのWebサイトを訪問してください。(<a href="http://www.yaml.org/">http://www.yaml.org/</a>)</p>

<p>まず第一に、タブは使いません; 代わりに半角のスペース(ブランク)を使います。YAMLパーサーはタブを含むファイルを理解できないので、リスト5-1で示すようにスペースで行をインデントします(2つのスペースはsymfonyの規約です)。</p>

<p>リスト5-1 YAMLファイルはタブを禁止する</p>

<pre><code># タブは使わない
all:
-&gt; mail:
-&gt; -&gt; webmaster:  webmaster@example.com

# 代わりに半角のスペースを使う
all:
  mail:
    webmaster: webmaster@example.com
</code></pre>

<p>パラメーターがスペースで始まるもしくは終わる文字列である場合、シングルクォート(')で値をとり囲みます。リスト5-2で示されるように、文字列のパラメーターが特別な文字を含むのであれば、その値もシングルクォートでとり囲んでください。</p>

<p>リスト5-2 - 非標準的な文字列はシングルクォートで閉じる</p>

<pre><code>error1: This field is compulsory
error2: '  This field is compulsory  '
error3: 'Don''t leave this field blank'   # シングルクォートは二重でなければならない
</code></pre>

<p>特別な文字列のヘッダー(>(大なり記号)と|(縦線・パイプライン))と追加のインデントを用いることで、複数行の長い文字列と複数行の文字列も定義できます。リスト5-3はこの規約を示しています。</p>

<p>リスト5-3 - 複数行の長い文字列を定義する</p>

<pre><code># &gt;(大なり記号)で導入される、折り返しスタイル
# それぞれの改行はスペースで折り返される
# YAMLがより読みやすくなる
accomplishment: &gt;
  Mark set a major league
  home run record in 1998.

# |(縦線・パイプライン)によって導入される、リテラルスタイル
# すべての改行はカウントされる
# インデントは結果の文字列に表示されない
stats: |
  65 Home Runs
  0.278 Batting Average
</code></pre>

<p>値を配列として定義するには、リスト5-4で示されるように、要素を角かっこ([、])で閉じるかダッシュ(-)を用いた拡張構文を使います。</p>

<p>リスト5-4 - YAMLの配列構文</p>

<pre><code># 配列のための省略構文
players: [ Mark McGwire, Sammy Sosa, Ken Griffey ]

# 配列のための拡張構文
players:
  - Mark McGwire
  - Sammy Sosa
  - Ken Griffey
</code></pre>

<p>値を連想配列もしくはハッシュとして定義するには、波かっこ({、})で要素をとり囲み、<code>key: value</code>の組のようにキーと値の間に空白文字を挿入します。リスト5-5で示されるように、すべての新しいキーに対して、インデントとキャリッジ・リターン(CR)を追加することで拡張構文も利用できます。</p>

<p>リスト5-5 - YAMLの連想配列構文</p>

<pre><code># 正しくない構文、スペースがコロンのあとで見つからない
mail: {webmaster:webmaster@example.com,contact:contact@example.com}

# 連想配列のための正しい省略構文
mail: { webmaster: webmaster@example.com, contact: contact@example.com }

# 連想配列のための拡張構文
mail:
  webmaster: webmaster@example.com
  contact:   contact@example.com
</code></pre>

<p>ブール値を追加するには、正の値に対しては<code>on</code>、<code>1</code>、もしくは<code>true</code>、負の値に対して<code>off</code>、<code>0</code>もしくは<code>false</code>のいずれかを使います。リスト5-6では可能なブール値が示されています。</p>

<p>リスト5-6 - ブール値のYAML構文</p>

<pre><code>true_values:   [ on, 1, true ]
false_values:  [ off, 0, false ]
</code></pre>

<p>リスト5-7で示されるように、YAMLファイルを読みやすくするための(ハッシュ記号の<code>#</code>で始まる)コメント追加や、値へのスペースの追加をためらう必要はありません。</p>

<p>リスト5-7 - YAMLのコメント構文と値の位置合わせ</p>

<pre><code># これはコメント行
mail:
  webmaster: webmaster@example.com
  contact:   contact@example.com
  admin:     admin@example.com   # 追加のスペースのおかげで値をわかりやすく配置できる
</code></pre>

<p>symfonyの設定ファイルにおいて、ハッシュ記号で始まる行(コメントとしてYAMLパーサーによって無視される)を見ることがありますが、通常の設定行のように見えます。これはsymfonyの規約です: デフォルトの設定、symfonyのコアに設置されたほかのYAMLファイルから継承されたものは、アプリケーションの設定のなかでコメント行として繰り返されます。このようなパラメーターの値を変更したい場合、リスト5-8で示されるように、行の最初をアンコメントする必要があります。</p>

<p>リスト5-8 - デフォルトの設定はコメントとして示される</p>

<pre><code># キャッシュはデフォルトでoff
settings:
# cache: off

# この設定を変更したい場合、最初の行をアンコメントする
settings:
  cache: on
</code></pre>

<p>時々symfonyはパラメーターの定義をカテゴリに分類します。任意のカテゴリのすべての設定はカテゴリのヘッダーの下でインデントされて表示されます。<code>key: value</code>の一組の長いリストをカテゴリに分類してこれらを構造化することで設定の読みやすさが改善されます。カテゴリのヘッダーはドット(<code>.</code>)で始まります。リスト5-9ではカテゴリの例が示されています。</p>

<p>リスト5-9 - カテゴリのヘッダーはキーのように見えるが、ドットで始まる</p>

<pre><code>all:
  .general:
    tax:        19.6

  mail:
    webmaster:  webmaster@example.com
</code></pre>

<p>この例では、<code>mail</code>がキーで<code>general</code>はカテゴリヘッダーのみです。リスト5-10で示されるように、そのカテゴリがあたかも存在しなかったようにすべてが機能します。<code>tax</code>パラメーターは実際には<code>all</code>キーの直接の子供です。しかしながらカテゴリーを利用することでsymfonyが<code>all</code>キーの真下に存在する配列を扱うための助けになります。</p>

<p>リスト5-10 - カテゴリヘッダーは読みやすくする目的のためだけに存在し、実際には無視される</p>

<pre><code>all:
  tax:          19.6

  mail:
    webmaster:  webmaster@example.com
</code></pre>

<blockquote class="sidebar"><p class="title">
  YAMLがお好きでなければ</p>
  
  <p>YAMLはPHPコードで使われる設定を定義するための単なるインターフェイスなので、YAMLで定義された設定はPHPに変換されることになります。ブラウザーでアプリケーションを見た後に、キャッシュされた設定を確認してください(たとえば、<code>cache/frontend/dev/config/</code>)。PHPファイルがYAML設定に対応していることがわかります。この章の後のほうで、もっと設定のキャッシュを学びます。</p>
  
  <p>YAMLファイルを使いたくないのであればよいお知らせがあります。PHPもしくは別のフォーマット(XML、INI、など)を通して設定ファイルを手動で設定できます。この本全体を通して、YAMLを使わずに設定を定義する別の方法に出会い、symfonyのコンフィギュレーションハンドラーを置き換える方法も学ぶことになります(19章)。これらを賢く使えば、これらのトリックによって設定ファイルを回避するもしくは独自の設定フォーマットを定義できます。</p>
</blockquote>

<a name="help.a.yaml.file.killed.my.app" id="help.a.yaml.file.killed.my.app"></a><h3>助けてください、YAMLファイルを修正したらアプリケーションが動かなくなりました！</h3>

<p>YAMLのファイルは解析されてPHPのハッシュと配列に変換されます。ビュー、コントローラー、もしくはモデルのふるまいを修正するために値はアプリケーションのさまざまな場所で使われます。多くの場合、YAMLのファイルに問題があるとき、値を実際に使う必要があるまで検出されません。その上、通常は投じられたエラーもしくは例外がYAMLの設定ファイルに関連しているのかどうかは明らかではありません。</p>

<p>設定を変更したあとでアプリケーションが突然機能を停止する場合、YAMLを記述するさいに共通の不注意な間違いをしなかったことを確認します:</p>

<ul>
<li><p>キーとその値の間のスペースを入れ忘れていないか:</p>

<pre><code>key1:value1      # :のあとでスペースが見つからない
</code></pre></li>
<li><p>連続したキーが同じ方法でインデントされていない:</p>

<pre><code>all:
  key1:  value1
   key2: value2  # インデントのレベルがほかの連続したメンバーと同じではない
  key3:  value3
</code></pre></li>
<li><p>文字列の区切り文字なしで、キーもしくは値にYAMLの予約文字が存在する:</p>

<pre><code>message: tell him: go way    # :(コロン)、[、](角かっこ)、{と}(中かっこ)はYAMLの予約文字
message: 'tell him: go way'  # 正しい構文
</code></pre></li>
<li><p>コメント行を修正している:</p>

<pre><code># key: value     # 見出しの#が原因で無視される
</code></pre></li>
<li><p>同じレベルで同じキーを持つ値を2回設定している:</p>

<pre><code>key1: value1
key2: value2
key1: value3     # key1 は2回定義され、値は最後に定義されたものになる
</code></pre></li>
<li><p>設定はつねに文字列であるにもかかわらず、変換するまで、設定が特別な型をとると考える:</p>

<pre><code>income: 12,345   # 変換するまで、これはまだ文字列
</code></pre></li>
</ul>

<a name="overview.of.the.configuration.files" id="overview.of.the.configuration.files"></a><h2>設定ファイルの概要</h2>

<p>設定は項目によってファイルに分割されます。ファイルはパラメーターの定義、もしくは設定を含みます。これらのパラメーターはいくつかのレベル(プロジェクト、アプリケーションとモジュール)でオーバーライドされます; パラメーターのなかには特定のレベル限定のものもあります。つぎの章でこれらのメイントピックに関連する設定ファイルを扱い、19章では高度な設定方法を扱います。</p>

<a name="project.configuration" id="project.configuration"></a><h3>プロジェクトのコンフィギュレーション</h3>

<p>デフォルトではプロジェクトの設定ファイルはわずかに存在します。<code>myproject/config/</code>ディレクトリのなかで見つかるファイルはつぎのとおりです:</p>

<ul>
<li><code>ProjectConfiguration.class.php</code>: これはリクエストもしくはコマンドによってとても最初の方でインクルードされるファイルです。これはフレームワークへのパスを含むので、異なるインストレーションを利用するために変更できます。このファイルの高度な使いかたに関しては19章を参照してください。</li>
<li><code>databases.yml</code>: このファイルはデータベースへのアクセスと接続の設定を定義する(ホスト名、ログイン名、パスワード、データベース名など)。8章でより詳しく説明します。このファイルをアプリケーションレベルでオーバーライドできます。</li>
<li><code>properties.ini</code>: このファイルは、プロジェクト名と異なるサーバーのための接続設定を含む、コマンドラインツールによって利用されるいくつかのパラメーターを保有します。このファイルを利用する機能の概要に関しては16章を参照してください。</li>
<li><code>rsync_exclude.txt</code>: このファイルはサーバー間の同期から除外されるディレクトリを指定します。設定方法は16章で検討します。</li>
<li><code>schema.yml</code>と<code>propel.ini</code>:これらはPropel(symfonyのORMレイヤー)によって使われるデータアクセス用の設定ファイルです。これらのファイルはPropelのライブラリとsymfonyのクラスとプロジェクトのデータを連携させるために使われます。<code>schema.yml</code>はプロジェクトのリレーショナルデータモデルの記述を含みます。<code>propel.ini</code>は自動的に生成されるので、修正する必要はおそらくありません。もしPropelを利用しないのであれば、これらのファイルは必要ありません。8章でこれらの使いかたに関する詳細な説明を行います。</li>
</ul>

<p>これらのファイルはおもに外部のコンポーネントもしくはコマンドラインによって使われる、もしくはsymfonyによって読み込まれるYAMLの解析プログラムよりも先に処理される必要があります。これらのなかにYAMLフォーマットを使わないものが存在するのはそういうわけです。</p>

<a name="application.configuration" id="application.configuration"></a><h3>アプリケーションのコンフィギュレーション</h3>

<p>設定のメイン部分はアプリケーションの設定です。アプリケーションの設定はメインの設定のためにフロントコントローラー(<code>web/</code>ディレクトリ)のなかで定義されます。YAMLファイルはアプリケーションの<code>config/</code>ディレクトリ、<code>i18n/</code>ディレクトリ、フレームワークディレクトリに設置されます。<code>i18n/</code>ディレクトリは国際化のために、フレームワークファイルは見えないが役に立つ追加のアプリケーション設定のためにあります。</p>

<a name="front.controller.configuration" id="front.controller.configuration"></a><h4>フロントコントローラーのコンフィギュレーション</h4>

<p>本当に最初のアプリケーションのコンフィギュレーションは実際にはフロントコントローラー内で見つかります; これはリクエストによって実行される最初のスクリプトです。リスト5-11のデフォルトの<code>web/index.php</code>をご覧ください。</p>

<p>リスト5-11 - 運用環境用のデフォルトのフロントコントローラー</p>

<pre class="php"><span class="kw2">&lt;?php</span>
&nbsp;
<span class="kw1">require_once</span><span class="br0">&#40;</span><span class="kw3">dirname</span><span class="br0">&#40;</span><span class="kw4">__FILE__</span><span class="br0">&#41;</span><span class="sy0">.</span><span class="st_h">'/../config/ProjectConfiguration.class.php'</span><span class="br0">&#41;</span><span class="sy0">;</span>
&nbsp;
<span class="re0">$configuration</span> <span class="sy0">=</span> ProjectConfiguration<span class="sy0">::</span><span class="me2">getApplicationConfiguration</span><span class="br0">&#40;</span><span class="st_h">'frontend'</span><span class="sy0">,</span> <span class="st_h">'prod'</span><span class="sy0">,</span> <span class="kw4">false</span><span class="br0">&#41;</span><span class="sy0">;</span>
sfContext<span class="sy0">::</span><span class="me2">createInstance</span><span class="br0">&#40;</span><span class="re0">$configuration</span><span class="br0">&#41;</span><span class="sy0">-&gt;</span><span class="me1">dispatch</span><span class="br0">&#40;</span><span class="br0">&#41;</span><span class="sy0">;</span></pre>

<p>アプリケーションの名前(<code>frontend</code>)と環境(<code>prod</code>)を定義したあとで、アプリケーションの設定はコンテキストとディスパッチングのまえに呼び出されます。ですのでアプリケーションの設定クラスのなかで利用できる便利なメソッドはわずかです:</p>

<ul>
<li><code>$configuration-&gt;getRootDir()</code>: プロジェクトのrootディレクトリ(通常は、ファイル構造を変更しないかぎり、デフォルト値のままにします)。</li>
<li><code>$configuration-&gt;getApplication()</code>: プロジェクトのアプリケーションの名前。ファイルのパスを算出するために必要。</li>
<li><code>$configuration-&gt;getEnvironment()</code>: 環境の名前(<code>prod</code>、<code>dev</code>、もしくはあなたが定義するプロジェクト固有の環境)。使われるコンフィギュレーション設定を決定します。環境はこの章の後ろの方で説明します。</li>
<li><code>$configuration-&gt;isDebug()</code>: デバッグモードの有効(詳細は16章)。</li>
</ul>

<p>これらの値の1つを変更したい場合、おそらく追加のフロントコントローラーが必要です。つぎの章でフロントコントローラーに関する詳細な情報と新しいフロントコントローラーを作成する方法をお伝えます。</p>

<a name="main.application.configuration" id="main.application.configuration"></a><h3>メインアプリケーションのコンフィギュレーション</h3>

<p>メインアプリケーションの設定は<code>myproject/apps/frontend/config/</code>ディレクトリに設置されたファイルに保存されます:</p>

<ul>
<li><code>app.yml</code>: このファイルはアプリケーション固有の設定です; すなわち、アプリケーションに固有なビジネスロジックもしくはアプリケーションロジックを定義するグローバル変数で、データベースに保存する必要のないものです。税率、運賃、Eメールアドレスはこのファイルによく保存されます。デフォルトではこのファイルは空です。</li>
<li><code>frontendConfiguration.class.php</code>: このクラスはアプリケーションを起動します。このことはアプリケーションを始めることができるようにするためのとても基本的な初期化を行うことを意味します。ここはディレクトリ構造もしくはアプリケーション固有の定数をカスタマイズする場所です(19章で詳細な情報を提供します)。これは<code>ProjectConfiguration</code>クラスから継承します。</li>
<li><code>factories.yml</code>: symfonyは、ビュー、リクエスト、リスポンス、セッション、などを扱う独自のクラスを定義します。代わりに独自のクラスを使いたい場合、ここでこれらを指定できます。17章で詳細な情報を提供します。</li>
<li><code>filters.yml</code>: フィルターはすべてのリクエストに対して実行されるコードの一部です。このファイルでは処理されるフィルターを定義し、それぞれのモジュールからオーバーライドできます。6章でこれらの詳細について検討します。</li>
<li><code>routing.yml</code>: ルーティングルールがこのファイルに保存されます。ルーティングルールはわかりづらくてブックマークしにくいURLを"スマート"(smart)で明快なものに変換します。新しいアプリケーションに対して、デフォルトのルールがいくつか存在します。9章でリンクとルーティングに関するすべての説明を行います。</li>
<li><code>settings.yml</code>: symfonyのアプリケーションの主要な設定はこのファイルで定義されます。このファイルでアプリケーションが国際化機能、デフォルトの言語、リクエストの有効期限とキャッシュにオンにするかなどを指定します。このファイル内で1行変更すれば、アプリケーションをシャットダウンできるのでメンテナンスを実行するもしくはコンポーネントの1つをアップグレードすることが可能です。共通の設定と使いかたは19章で説明します。</li>
<li><code>view.yml</code>: デフォルトのビューの構造(レイアウトの名前、インクルードされるデフォルトのスタイルシートとJavaScriptのファイル、デフォルトのcontent-type、など)はこのファイルのなかで設定されます。7章でこのファイルの詳細な情報をお伝えます。これらの設定はそれぞれのモジュールからオーバーライドできます。</li>
</ul>

<a name="internationalization.configuration" id="internationalization.configuration"></a><h4>国際化のコンフィギュレーション</h4>

<p>国際化されたアプリケーションはさまざまな言語のページを表示できます。このためには特別な設定が必要です。国際化のための設定を行う場所は2ヶ所あります:</p>

<ul>
<li>アプリケーションの<code>config/</code>ディレクトリの<code>factories.yml</code>: このファイルは国際化ファクトリと一般的な翻訳オプション、翻訳がファイルもしくはデータベースから由来するか、そしてそれらのフォーマットを定義します。</li>
<li>アプリケーションの<code>i18n</code>ディレクトリの翻訳ファイル: これらは基本的に辞書(dictionary)です。ユーザーが言語を切り替えたときにページが翻訳されたテキストを表示するようにアプリケーションのテンプレートのなかで使われるそれぞれのフレーズに対する翻訳を渡します。</li>
</ul>

<p>国際化機能の有効は<code>settings.yml</code>ファイルで設定されることに留意してください。これらに関する詳細な情報は13章で見つかります。</p>

<a name="additional.application.configuration" id="additional.application.configuration"></a><h4>アプリケーションの追加コンフィギュレーション</h4>

<p>設定ファイルの2番目の一式はsymfonyのインストレーションディレクトリ(<code>$sf_symfony_lib_dir/config/config/</code>)に存在し、アプリケーションの設定ディレクトリには表示されません。そこで定義された設定はほとんど修正する必要のないもしくはすべてのプロジェクトに対してグローバルであるデフォルトです。しかしながら、修正する必要がある場合、同じ名前を持つ空のファイルを<code>myproject/apps/frontend/config</code>ディレクトリに作り、変更したい設定をオーバーライドしてください。アプリケーションで定義された設定はフレームワークで定義された設定よりつねに優先されます。以下のものはsymfonyがインストールされた<code>config/</code>ディレクトリに存在する設定ファイルです:</p>

<ul>
<li><code>autoload.yml</code>: このファイルはオートロード機能の設定を含みます。カスタムクラスが指定されたディレクトリに設置されている場合、この機能のおかげでこれらのクラスをコード内でrequireを行わずにすみます。詳細は19章で説明します。</li>
<li><code>core_compile.yml</code>と<code>bootstrap_compile.yml</code>: これらは、(<code>bootstrap_compile.yml</code>で)アプリケーションを起動させ、(<code>core_compile.yml</code>で)リクエストを処理するために含まれるクラスのリストです。これらのクラスは実際には(コメントなしの)最適化された1つのPHPファイルに連結されます。このPHPファイルはファイルのアクセスオペレーションを最小にすることで実行速度を加速します(置き換えられた1つのファイルはそれぞれのリクエストに対して40倍以上速くロードされます)。これはとりわけPHPアクセレータを使わない場合に便利です。最適化のテクニックは18章で説明します。</li>
<li><code>config_handlers.yml</code>: このファイルのなかでそれぞれの設定ファイルを処理するハンドラーを追加もしくは修正できます。19章に詳細な説明があります。</li>
</ul>

<a name="module.configuration" id="module.configuration"></a><h3>モジュールのコンフィギュレーション</h3>

<p>デフォルトでは、モジュールは特別な設定を持ちません。しかしながら、必要ならば、任意のモジュールのためにいくつかのアプリケーションレベルの設定をオーバーライドできます。たとえば、1つのモジュールのすべてのアクションのために特定のJavaScriptファイルをインクルードするためにこれを行うことでしょう。カプセル化を保持するために指定されたモジュールに制限された新しいパラメーターを追加することを選択することもできます。</p>

<p>ご明察のとおり、モジュール設定ファイルは<code>myproject/aaps/frontend/modules/mymodules/config/</code>ディレクトリに設置しなければなりません。これらのファイルはつぎのとおりです:</p>

<ul>
<li><code>generator.yml</code>: (scaffoldingとadministrationを利用して)データベースのテーブルに対応して生成されたモジュールに対して、このファイルはインターフェイスが列とフィールドを表示する方法と、ユーザーに提示されるインタラクション(フィルター、ソート、ボタン、など)を定義します。14章でより詳細な内容を説明します。</li>
<li><code>module.yml</code>: このファイルはモジュールに固有なカスタムパラメーターとアクション設定を含みます。6章で詳細を説明します。</li>
<li><code>security.yml</code>: このファイルはアクションに対するアクセス制限を設定します。ここで登録ユーザーもしくは特別なパーミッションを持つ登録ユーザーの一部のみがページを閲覧できるように指定することができます。6章に詳細な説明があります。</li>
<li><code>view.yml</code>: このファイルはモジュールのアクションの1つもしくはすべてのビューのための設定を含みます。このファイルはアプリケーションの<code>view.yml</code>をオーバーライドします。7章で説明します。</li>
</ul>

<p>モジュールのたいていの設定ファイルは、すべてのビュー、もしくは1つのモジュールのすべてのアクション、もしくはそれらの一部に対して、パラメーターを追加する機能を提供します。</p>

<blockquote class="sidebar"><p class="title">
  ファイルが多すぎるでしょうか？</p>
  
  <p>アプリケーション内部に存在する設定ファイルの数に圧倒されているかもしれません。しかしながらつぎのことを念頭に置いて下さるようお願いします:</p>
  
  <p>たいていの場合、デフォルトの規約が多くの共通の要件を満たすので、設定を変更する必要はありません。それぞれの設定ファイルは特定の機能に関係し、つぎの章でこれらの使いかたを一つずつ説明します。単独のファイルをとり組むとき、それが何を行い、どのように編成されているのかわかります。プロフェッショナルなWeb開発のために、しばしデフォルトの設定は完全には適用されません。設定ファイルによってsymfonyのメカニズムをコードなしで簡単に修正できます。同じ量のコントロールを実現するために必要なPHPのコード量を想像してください。すべての設定が1つのファイルに設置されたとしたら、ファイルに完全な可読性がなくなるだけでなく、いくつかのレベルで設定を再定義できなくなります(この章の後のほうにある"設定カスケード"をご覧ください)。</p>
  
  <p>設定システムはsymfonyのすばらしい強みの1つです。これによって、元来対象としたWebアプリケーションだけでなく、ほかのほとんどすべてのアプリケーションに対してもsymfonyを利用できるからです。</p>
</blockquote>

<a name="environments" id="environments"></a><h2>環境</h2>

<p>アプリケーションの開発過程で、おそらく平行していくつかの設定の一式を保有することが必要になります。たとえば、開発期間にテストのデータベースのための接続設定と、運用環境で利用できる実際のデータのための接続設定が必要になるでしょう。同時に設定する方法の需要に応えるために、symfonyは異なる環境(environment)を提供します。</p>

<a name="what.is.an.environment" id="what.is.an.environment"></a><h3>環境とは何か？</h3>

<p>アプリケーションはさまざまな環境(environment)のもとで動くことができます。異なる環境は同じPHPコード(フロントコントローラーは別)を共有しますが、、完全に異なる設定を持つことができます。それぞれのアプリケーションに対して、symfonyは3つの異なるデフォルト環境を提供します: 運用(<code>prod</code>)、テスト(<code>test</code>)、と開発(<code>dev</code>)です。欲しい数だけカスタム環境を追加することも自由にできます。</p>

<p>ですので、基本的には、環境(environment)と設定(コンフィギュレーション)(configuration)は同義語です。たとえば、<code>test</code>環境では警告とエラーが記録されるのに対して、<code>prod</code>環境ではエラーのみが記録します。キャッシュのアクセラレータは<code>dev</code>環境ではよく無効にされますが、<code>test</code>と<code>prod</code>環境では有効にされます。<code>dev</code>と<code>test</code>環境ではテストデータが必要になることがあります。テストデータは運用環境で使われるものとは別にデータベースに保存されます。ですので2つの環境のあいだでデータベースの設定は異なります。すべての環境は同じマシン上に同居できますが、運用サーバーは一般的に<code>prod</code>環境のみを含みます。</p>

<p><code>dev</code>環境において、メンテナンスはパフォーマンスよりも重要なので、ロギングとデバッグの設定はすべて有効です。一方で、<code>prod</code>環境はデフォルトでパフォーマンスを最適化した設定を持つので、運用環境の設定では多くの機能をオフです。よい経験則はとり組んでいる機能に満足するまで開発環境でとり組み、運用環境に切り替えてからはスピードをチェックします。</p>

<p><code>test</code>環境はつぎの点で<code>dev</code>と<code>prod</code>環境とは異なります。機能テストとバッチスクリプトを組むためにコマンドラインを通してのみこの環境と関わることになります。結果として、<code>test</code>環境は運用環境と近いですが、Webブラウザーでアクセスできません。Cookieの使用とほかのHTTP固有のコンポーネントをシミュレートします。</p>

<p>ブラウザーで閲覧しているアプリケーションの環境を変更するには、フロントコントローラーを変更するだけです。これまでは開発環境だけを見てきました。例で使われたURLは開発用のフロントコントローラーを呼び出していたからです:</p>

<pre><code>http://localhost/frontend_dev.php/mymodule/index
</code></pre>

<p>しかしながら、運用環境でアプリケーションが応対する様子を見たいのであれば、運用環境用のフロントコントローラーを呼び出します:</p>

<pre><code>http://localhost/index.php/mymodule/index
</code></pre>

<p>Webサーバーがmod_rewriteを有効にしている場合、<code>web/.htaccess</code>に書かれている、symfonyのカスタム書き換えルールを利用できます。これらのルールは運用環境用のフロントコントローラーをデフォルトの実行スクリプトとして定義し、つぎのようなURLを許可します:</p>

<pre><code>http://localhost/mymodule/index
</code></pre>

<blockquote class="sidebar"><p class="title">
  環境とサーバー</p>
  
  <p>環境とサーバーの概念を混同しないでください。symfonyにおいて、異なる環境は異なる設定でフロントコントローラー(リクエストを実行するスクリプト)に対応します。異なるサーバーはURLの異なるドメイン名に対応します。</p>

<pre><code>http://localhost/frontend_dev.php/mymodule/index
       _________ _____________
        サーバー  　環境
</code></pre>
  
  <p>通常、開発者は開発サーバーのなかのアプリケーションにとり組みます。開発サーバーではインターネットから切り離され、すべてのサーバーとPHPの設定を自由に変更できます。アプリケーションを運用環境にリリースする時期が来たとき、アプリケーションのファイルを運用サーバーに転送して、エンドユーザーがアクセスできるようにします。</p>
  
  <p>このことは多くの環境がそれぞれのサーバー上で利用できることを意味します。たとえば、開発サーバー上でも運用環境で運用できます。しかしながら、たいていの場合、サーバーの設定を公開することとセキュリティのリスクを避けるために、運用環境のみ運用サーバーにアクセスできます。運用システム上の開発用ではないコントローラーを誤って流出させることを避けるために、symfonyは基本的なIPチェックをこれらのコントローラーに追加します。このことによってlocalhostからのみアクセスできるようになります。削除できるこれらにアクセスできるようにしたい場合、悪意のあるユーザーはデフォルトの<code>frontend_dev.php</code>を推測して多くのデバッグ情報にアクセスできるので、これを誰でもアクセスできるようにすることのリスクを考えてください。</p>
  
  <p>新しい環境を追加するには、新しいディレクトリを作るもしくはsymfonyのCLIを使う必要はありません。単に新しいフロントコントローラーを作り、環境の名前の定義を変更するだけです。この環境はすべての環境に共通の設定に加えてデフォルトのすべての設定を継承します。つぎの章でこれを行う方法を示します。</p>
</blockquote>

<a name="configuration.cascade" id="configuration.cascade"></a><h3>設定カスケード</h3>

<p>同じ設定を異なった場所で、一回以上定義できます。たとえば、すべてのアプリケーションに対して、<code>text/xml mime-typeが必要な</code>rss<code>モジュールのページを除いて、mime-typeのページを</code>text/html<code>に設定することを考えます。symfonyは最初の設定を</code>frontend/config/view.yml<code>に書いて、2番目に</code>frontend/modules/rss/config/view.yml`に書く機能を提供します。設定システムはモジュールレベルで定義された設定はアプリケーションレベルで定義された設定をオーバーライドしなければならないことを知っています。</p>

<p>実際、symfonyにはいくつかの設定レベルが存在します:</p>

<ul>
<li>粒度のレベル:

<ul>
<li>フレームワーク内に設置されたデフォルトの設定</li>
<li>プロジェクト全体のためのグローバル設定(<code>myproject/config/</code>)</li>
<li>プロジェクトのアプリケーションのためのローカル設定(<code>myproject/apps/frontend/config/</code>)</li>
<li>モジュールに制限されたローカル設定(<code>myproject/apps/frontend/modules/mymodule/config/</code>)</li>
</ul></li>
<li>環境レベル:

<ul>
<li>ある環境に固有</li>
<li>すべての環境用</li>
</ul></li>
</ul>

<p>カスタマイズできるすべてのプロパティのうち、多くは環境に依存します。結果として、すべての環境のための末尾の部分に加えて、多くのYAMLの設定ファイルは環境によって分割されます。よくあるsymfonyの設定はリスト5-12のようになります。</p>

<p>リスト5-12 - symfonyの設定ファイルの構造</p>

<pre><code># 運用環境の設定
prod:
  ...

# 開発環境の設定
dev:
  ...

# テスト環境の設定
test:
  ...

# カスタム環境の設定
myenv:
  ...

# すべての環境のための設定
all:
  ...
</code></pre>

<p>加えて、このフレームワーク自身は、プロジェクトのツリー構造ではなく、symfonyインストレーションの<code>$sf_symfony_lib_dir/config/config/</code>ディレクトリに設置されたファイルでデフォルト値を定義します。リスト5-13で示されるようにデフォルトの設定はこれらのファイルで設定されます。これらの設定はすべてのアプリケーションによって継承されます。</p>

<p>リスト5-13 - デフォルト設定(<code>$sf_symfony_lib_dir/config/config/settings.yml</code>)</p>

<pre><code> # デフォルト設定:
 default:
   default_module:         default
   default_action:         index
   ...
</code></pre>

<p>リスト5-14で示されるように、これらのデフォルトの定義はプロジェクト、アプリケーション、モジュールの設定ファイルのなかでコメントとして繰り返されるので、いくつかのパラメーターはデフォルトで定義されこれらが修正可能であることはご存じのとおりです。</p>

<p>リスト5-14 - 報のために繰り返される、デフォルト設定(<code>frontend/config/settings.yml</code>)</p>

<pre><code>#all:
#  default_module:         default
#  default_action:         index
#...
</code></pre>

<p>このことはプロパティは何度も定義することが可能で、実際の値は定義のカスケードから由来します。名前つきの環境のパラメーター定義はすべての環境のための同じパラメーター定義より優先され、すべての環境のための定義はデフォルトの定義より優先されます。モジュールレベルでのパラメーター定義はアプリケーションレベルでの同じパラメーター定義よりも優先されます。アプリケーションレベルでの定義はプロジェクトレベルでの定義より優先されます。これはつぎの優先順位のリストにまとめることができます:</p>

<ol>
<li>モジュール</li>
<li>アプリケーション</li>
<li>プロジェクト</li>
<li>特別な環境</li>
<li>すべての環境</li>
<li>デフォルト</li>
</ol>

<a name="the.configuration.cache" id="the.configuration.cache"></a><h2>コンフィギュレーションキャッシュ</h2>

<p>実行時のYAMLの解析と設定カスケードの処理はそれぞれのリクエストに対する深刻なオーバーヘッドを意味します。symfonyはリクエストを迅速にするために設計された組み込みのコンフィギュレーションキャッシュのメカニズムを持ちます。</p>

<p>設定ファイルは、フォーマットが何であれ、ハンドラー(handler)と呼ばれる、いくつかの特別なクラスによって処理され、これらのファイルは速く処理されるPHPコードに変換されます。開発環境において、インタラクティビティを推進するために、ハンドラーはリクエストごとの変更に対して設定をチェックします。これらは最近修正されたファイルを解析するのでYAMLファイルのなかの変更を即座に確認できます。しかしながら、運用環境においては、最初のリクエストの間に処理が一回行われ、その後のリクエストのために処理すみのPHPコードはキャッシュに保存されます。運用環境においてすべてのリクエストは十分に最適化されたPHPコードを実行するので、パフォーマンスは保証されます。</p>

<p>たとえば、<code>app.yml</code>ファイルがつぎの内容を含むとします:</p>

<pre><code>all:                   # すべての環境のための設定
  mail:
    webmaster:         webmaster@example.com
</code></pre>

<p>それから、プロジェクトの<code>cache/</code>フォルダーに設置された、<code>config_app.yml.php</code>ファイルはつぎの内容を含みます:</p>

<pre class="php"><span class="kw2">&lt;?php</span>
&nbsp;
sfConfig<span class="sy0">::</span><span class="me2">add</span><span class="br0">&#40;</span><span class="kw3">array</span><span class="br0">&#40;</span>
  <span class="st_h">'app_mail_webmaster'</span> <span class="sy0">=&gt;</span> <span class="st_h">'webmaster@example.com'</span><span class="sy0">,</span>
<span class="br0">&#41;</span><span class="br0">&#41;</span><span class="sy0">;</span></pre>

<p>結果として、多くの場合、YAMLのファイルはsymfonyによって解析されず、代わりにコンフィギュレーションキャッシュに依存します。しかしながら、開発環境において、symfonyは体系的にYAMLファイルの修正の日付とキャッシュされたファイルを比較し、以前のリクエスト以降に変更されたファイルだけを再処理します。</p>

<p>このことは、運用環境でもリクエストごとに設定ファイルがコンパイルされる多くのPHPフレームワークよりも優れた強みを示しています。Javaと異なり、PHPはリクエスト間の実行コンテキストを共有しません。ほかのPHPフレームワークに関しては、XMLの設定ファイルの柔軟性を維持すると、リクエストごとにすべての設定を処理するために余分な負荷(パフォーマンスヒット)が多く必要になります。しかしながらsymfonyにはこのことがあてはまりません。キャッシュシステムのおかげで、設定によって引き起こされるオーバーヘッドはとても低いものになっています。</p>

<p>このメカニズムには考慮するべきことがあります。製品環境で設定を変更した場合、修正を考慮したすべての設定ファイルの再解析を強制する必要があります。そのためには、キャッシュをクリアする必要があります。キャッシュをクリアするには<code>cache/</code>ディレクトリの内容を削除するか、symfonyの<code>cache:clear</code>タスクを呼び出します:</p>

<pre><code>&gt; php symfony cache:clear
</code></pre>

<a name="accessing.the.configuration.from.code" id="accessing.the.configuration.from.code"></a><h2>コードから設定にアクセスする</h2>

<p>すべてのファイルは最終的にはPHPに変換され、それらが含む多くの設定は干渉なしでフレームワークによって自動的に使われます。しかしながら、時々設定ファイルで定義されたいくつかの設定をコード(アクション、テンプレート、カスタムクラスなど)からアクセスする必要があります。<code>settings.yml</code>、<code>app.yml</code>、<code>module.yml</code>と<code>i18n.yml</code>のなかで定義された設定は<code>sfConfig</code>という名前の特別なクラスを通して利用できます。</p>

<a name="the.sfconfig.class" id="the.sfconfig.class"></a><h3>sfConfigクラス</h3>

<p><code>sfConfig</code>クラスを通してアプリケーションのコードの範囲から設定にアクセスできます。このクラスはシンプルなゲッタークラスのメソッドを持つ、設定パラメーターのためのレジストリで、コードのすべての部分からアクセスできます:</p>

<pre class="php"><span class="co1">// 設定を読みとる</span>
<span class="re0">$parameter</span> <span class="sy0">=</span> sfConfig<span class="sy0">::</span><span class="me2">get</span><span class="br0">&#40;</span><span class="st_h">'param_name'</span><span class="sy0">,</span> <span class="re0">$default_value</span><span class="br0">&#41;</span><span class="sy0">;</span></pre>

<p>PHPコードの範囲から設定を定義、オーバーライドすることもできます:</p>

<pre class="php"><span class="co1">// 設定を定義する</span>
sfConfig<span class="sy0">::</span><span class="me2">set</span><span class="br0">&#40;</span><span class="st_h">'param_name'</span><span class="sy0">,</span> <span class="re0">$value</span><span class="br0">&#41;</span><span class="sy0">;</span></pre>

<p>パラメーター名は、以下の順番で、アンダースコア(_)によって分割されたいくつかの要素を連結したものです:</p>

<ul>
<li>設定ファイル名に関連するプレフィックス(<code>sf_</code>は<code>settings.yml</code>、<code>app_</code>は<code>app.yml</code>、<code>mod_</code>は<code>module.yml</code>)</li>
<li>親キーは小文字(定義されている場合)</li>
<li>キーの名前は小文字</li>
</ul>

<p>PHPコードは実行される環境のために定義された値だけにアクセスするので、環境は含まれません。</p>

<p>たとえば、リスト5-15で示されるapp.ymlファイルのなかで定義される値にアクセスする必要がある場合、リスト5-16で示されているようなコードが必要です。</p>

<p>リスト5-15 - <code>app.yml</code>の設定のサンプル</p>

<pre><code>all:
  .general:
    tax:          19.6
  default_user:
    name:         John Doe
  mail:
    webmaster:    webmaster@example.com
    contact:      contact@example.com
dev:
  mail:
    webmaster:    dummy@example.com
    contact:      dummy@example.com
</code></pre>

<p>リスト5-16 - PHPのコードで<code>dev</code>環境のコンフィギュレーション設定にアクセスする</p>

<pre class="php"><span class="kw1">echo</span> sfConfig<span class="sy0">::</span><span class="me2">get</span><span class="br0">&#40;</span><span class="st_h">'app_tax'</span><span class="br0">&#41;</span><span class="sy0">;</span>   <span class="co1">// カテゴリのヘッダーが無視されることは覚えておく</span>
 <span class="sy0">=&gt;</span> <span class="st_h">'19.6'</span>
<span class="kw1">echo</span> sfConfig<span class="sy0">::</span><span class="me2">get</span><span class="br0">&#40;</span><span class="st_h">'app_default_user_name'</span><span class="br0">&#41;</span><span class="sy0">;</span>
 <span class="sy0">=&gt;</span> <span class="st_h">'John Doe'</span>
<span class="kw1">echo</span> sfConfig<span class="sy0">::</span><span class="me2">get</span><span class="br0">&#40;</span><span class="st_h">'app_mail_webmaster'</span><span class="br0">&#41;</span><span class="sy0">;</span>
 <span class="sy0">=&gt;</span> <span class="st_h">'dummy@example.com'</span>
<span class="kw1">echo</span> sfConfig<span class="sy0">::</span><span class="me2">get</span><span class="br0">&#40;</span><span class="st_h">'app_mail_contact'</span><span class="br0">&#41;</span><span class="sy0">;</span>
 <span class="sy0">=&gt;</span> <span class="st_h">'dummy@example.com'</span></pre>

<p>すべての値を変更できるので、symfonyのコンフィギュレーション設定はPHP定数のすべての利点を持ちますが、不利な点はともないません。</p>

<p>このため、アプリケーションのためにsymfonyの設定を行うことができる、<code>settings.yml</code>ファイルは<code>sfConfig::set()</code>呼び出しのリストと同等です。リスト5-17はリスト5-18で示されるようなコードとして解釈されます。</p>

<p>リスト5-17 - <code>settings.yml</code>の抜粋</p>

<pre><code>all:
  .settings:
    available:              on
    path_info_array:        SERVER
    path_info_key:          PATH_INFO
    url_format:             PATH
</code></pre>

<p>リスト5-18 - <code>settings.yml</code>を解析するときにsymfonyが行うこと</p>

<pre class="php">sfConfig<span class="sy0">::</span><span class="me2">add</span><span class="br0">&#40;</span><span class="kw3">array</span><span class="br0">&#40;</span>
  <span class="st_h">'sf_available'</span> <span class="sy0">=&gt;</span> <span class="kw4">true</span><span class="sy0">,</span>
  <span class="st_h">'sf_path_info_array'</span> <span class="sy0">=&gt;</span> <span class="st_h">'SERVER'</span><span class="sy0">,</span>
  <span class="st_h">'sf_path_info_key'</span> <span class="sy0">=&gt;</span> <span class="st_h">'PATH_INFO'</span><span class="sy0">,</span>
  <span class="st_h">'sf_url_format'</span> <span class="sy0">=&gt;</span> <span class="st_h">'PATH'</span><span class="sy0">,</span>
<span class="br0">&#41;</span><span class="br0">&#41;</span><span class="sy0">;</span></pre>

<p><code>settings.yml</code>ファイルのなかで見つかる設定の意味に関しては19章を参照してください。</p>

<a name="custom.application.settings.and.app.yml" id="custom.application.settings.and.app.yml"></a><h3>アプリケーションのカスタム設定とapp.yml</h3>

<p>アプリケーションの機能に関連する多くの設定は<code>myproject/apps/frontend/config/</code>ディレクトリに設置された<code>app.yml</code>に保存されます。このファイルは環境に依存しており、デフォルトでは空です。すべての設定は簡単に変更できます。コードからこれらの設定にアクセスするために<code>sfConfig</code>クラスを使います。リスト5-19は例を示しています。</p>

<p>リスト5-19 - 特定のサイトに対して受理されたクレジットカードのオペレータを定義する<code>app.yml</code>のサンプル</p>

<pre><code>all:
  creditcards:
    fake:             off
    visa:             on
    americanexpress:  on

dev:
  creditcards:
    fake:             on
</code></pre>

<p><code>fake</code>のクレジットカードが現在の環境で受理されるか知るには、つぎの値を取得します:</p>

<pre class="php">sfConfig<span class="sy0">::</span><span class="me2">get</span><span class="br0">&#40;</span><span class="st_h">'app_creditcards_fake'</span><span class="br0">&#41;</span><span class="sy0">;</span></pre>

<blockquote class="note"><p>
  <code>all</code>キーの真下でPHPの配列が必要なときカテゴリヘッダーを使うことが必要です。そうでなければ上記で示されたようにsymfonyは値を個別に利用できるようにします。</p>

<pre><code>all:
  .array:
    creditcards:
      fake:             off
      visa:             on
      americanexpress:  on

[php]
print_r(sfConfig::get('app_creditcards'));

Array(
  [fake] =&gt; false
  [visa] =&gt; true
  [americanexpress] =&gt; true
)
</code></pre>
  
  <p><strong>TIP</strong>
  1つのスクリプト内部で、定数もしくは設定を定義をしたくなるたびに、<code>app.yml</code>ファイルに設置するほうがよいのかどうかを考えてください。このファイルはすべてのアプリケーションの設定を保存するためにとても便利な場所です。</p>
</blockquote>

<p><code>app.yml</code>の構文を処理するのが難しくなったカスタムパラメーターが必要なとき、独自の構文を定義することが必要になるかもしれません。その場合、設定を新しいファイルに保存することができます。この設定は新しいコンフィギュレーションハンドラーによって解釈されます。コンフィギュレーションハンドラーに関する詳しい情報に関しては19章を参照してください。</p>

<a name="tips.for.getting.more.from.configuration.files" id="tips.for.getting.more.from.configuration.files"></a><h2>設定ファイルからより多くの情報を得るためのティップス</h2>

<p>独自のYAMLファイルを書くまえに学ぶべきトリックがいくつかあります。これらによって設定の重複を回避し、独自のYAMLフォーマットを扱うことができます。</p>

<a name="using.constants.in.yaml.configuration.files" id="using.constants.in.yaml.configuration.files"></a><h3>定数をYAML設定ファイルのなかで利用する</h3>

<p>いくつかのコンフィギュレーション設定はほかの設定の値に依存します。同じ値を2度設定することを避けるために、symfonyはYAMLファイル形式で定数をサポートします。パーセント記号(<code>%</code>)で囲まれた大文字の設定名(<code>sfConfig::get()</code>でアクセス可能)を見てみると、コンフィギュレーションハンドラーはこれらの設定を現在の値に置き換えます。例に関しては5-20のリストをご覧ください。</p>

<p>リス5-20 - YAMLファイル形式で定数を使う、<code>autoload.yml</code>からの例</p>

<pre><code>autoload:
  symfony:
    name:           symfony
    path:           %SF_SYMFONY_LIB_DIR%
    recursive:      on
    exclude:        [vendor]
</code></pre>

<p><code>path</code>パラメーターは<code>sfConfig::get('sf_symfony_lib_dir')</code>によって返された値をとります。多の設定ファイルに依存する1つの設定ファイルが欲しい場合、あなたが依存するファイルがすでに解析されたことを確認する必要があります(解析された設定ファイルの順番を理解するにはsymfonyのソースを調べてください)。<code>app.yml</code>は解析される最後のファイルの1つなので、そのファイルで別のものに依存することがあります。</p>

<a name="using.scriptable.configuration" id="using.scriptable.configuration"></a><h3>スクリプトを設定に組み込む</h3>

<p>設定が外部パラメーター(たとえばデータベース、またはほかの設定ファイル)に依存することがあります。このような特別の場合に対処するために、symfonyの設定ファイルはYAMLパーサーに渡されるまえにPHPファイルとして解析されます。このことは、リスト5-21のように、PHPコードをYAMLファイル内部に設置できることを意味します。</p>

<p>リスト5-21 - PHPのコードをYAMLファイルに含めることができる</p>

<pre><code>all:
  translation:
    format:  &lt;?php echo (sfConfig::get('sf_i18n') == true ? 'xliff' : 'none')."\n" ?&gt;
</code></pre>

<p>しかしながら設定はリクエストのかなり初期の間に解析されるので、助けをしてくれるsymfonyの組み込みメソッドもしくは関数が存在しないことにご注意ください。</p>

<p>また、デフォルトで<code>echo</code>言語構造はCR(キャリッジ・リターン)を追加しないので、YAMLフォーマットを有効に保つために"\n"もしくは<code>echoln</code>ヘルパーを追加する必要があります。</p>

<pre><code>all:
  translation:
    format:  &lt;?php echoln(sfConfig::get('sf_i18n') == true ? 'xliff' : 'none') ?&gt;
</code></pre>

<blockquote class="caution"><p>
  運用環境において、設定はキャッシュされるので、設定ファイルはキャッシュがクリアされたあとで一回だけ解析されます(そして実行されます)。</p>
</blockquote>

<a name="browsing.your.own.yaml.file" id="browsing.your.own.yaml.file"></a><h3>独自のYAMLファイルを読み込む</h3>

<p>YAMLファイルを直接読み込みたいときは、いつでも<code>sfYaml</code>クラスが使えます。このクラスはYAMLファイルをPHPの連想配列に変換できるYAMLパーサーです。リスト5-22はサンプルのYAMLファイルを表し、リスト5-23は解析方法を示しています。</p>

<p>リスト5-22 - <code>test.yml</code>ファイルのサンプル</p>

<pre><code>house:
  family:
    name:     Doe
    parents:  [John, Jane]
    children: [Paul, Mark, Simone]
  address:
    number:   34
    street:   Main Street
    city:     Nowheretown
    zipcode:  12345
</code></pre>

<p>リスト5-23 - YAMLファイルを連想配列に変換する<code>sfYaml</code>クラスを使う</p>

<pre class="php"><span class="re0">$test</span> <span class="sy0">=</span> sfYaml<span class="sy0">::</span><span class="me2">load</span><span class="br0">&#40;</span><span class="st_h">'/path/to/test.yml'</span><span class="br0">&#41;</span><span class="sy0">;</span>
<span class="kw3">print_r</span><span class="br0">&#40;</span><span class="re0">$test</span><span class="br0">&#41;</span><span class="sy0">;</span>
&nbsp;
<span class="kw3">Array</span><span class="br0">&#40;</span>
  <span class="br0">&#91;</span>house<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> <span class="kw3">Array</span><span class="br0">&#40;</span>
    <span class="br0">&#91;</span>family<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> <span class="kw3">Array</span><span class="br0">&#40;</span>
      <span class="br0">&#91;</span>name<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> Doe
      <span class="br0">&#91;</span>parents<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> <span class="kw3">Array</span><span class="br0">&#40;</span>
        <span class="br0">&#91;</span><span class="nu0">0</span><span class="br0">&#93;</span> <span class="sy0">=&gt;</span> John
        <span class="br0">&#91;</span><span class="nu0">1</span><span class="br0">&#93;</span> <span class="sy0">=&gt;</span> Jane
      <span class="br0">&#41;</span>
      <span class="br0">&#91;</span>children<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> <span class="kw3">Array</span><span class="br0">&#40;</span>
        <span class="br0">&#91;</span><span class="nu0">0</span><span class="br0">&#93;</span> <span class="sy0">=&gt;</span> Paul
        <span class="br0">&#91;</span><span class="nu0">1</span><span class="br0">&#93;</span> <span class="sy0">=&gt;</span> Mark
        <span class="br0">&#91;</span><span class="nu0">2</span><span class="br0">&#93;</span> <span class="sy0">=&gt;</span> Simone
      <span class="br0">&#41;</span>
    <span class="br0">&#41;</span>
    <span class="br0">&#91;</span>address<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> <span class="kw3">Array</span><span class="br0">&#40;</span>
      <span class="br0">&#91;</span>number<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> <span class="nu0">34</span>
      <span class="br0">&#91;</span>street<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> Main Street
      <span class="br0">&#91;</span>city<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> Nowheretown
      <span class="br0">&#91;</span>zipcode<span class="br0">&#93;</span> <span class="sy0">=&gt;</span> <span class="nu0">12345</span>
    <span class="br0">&#41;</span>
  <span class="br0">&#41;</span>
<span class="br0">&#41;</span></pre>

<a name="summary" id="summary"></a><h2>まとめ</h2>

<p>symfonyは設定システム(configuration system)をシンプルで読みやすくするためにYAMLフォーマットを利用します。複数の環境(environment)を扱い定義のカスケードを通してパラメーターを設定する機能によって開発者は多彩なことができます。設定のなかには<code>sfConfig</code>オブジェクトを通してコードの範囲内からアクセスできるものが存在します。とりわけアプリケーションの設定は<code>app.yml</code>ファイルに保存されます。</p>

<p>もちろん、symfonyはたくさんの設定ファイルを持ちますが、このアプローチによってsymfonyはより適合性のあるものになります。アプリケーションが高度なレベルのカスタマイズを必要としないのであれば、これらの設定ファイルに悩む必要がないことを覚えておいてください。</p>
</div>
<div class="navigation">
<hr/>
<table width="100%">
<tr>
<td width="40%" align="left"><a href="04-The-Basics-of-Page-Creation.html">前の章</a></td>
<td width="20%" align="center"><a href="index.html">ホーム</a></td>
<td width="40%" align="right"><a href="06-Inside-the-Controller-Layer.html">次の章</a></td>
</tr>
</table>

</div>
</body>

</html>
